1. Field of the Invention
This invention relates to protecting data stored on a data storage device.
2. Related Art
Many computational devices have a data storage device associated therewith. It can be desirable to protect sensitive data stored on the data storage device from unauthorized access. (Herein, “data” refers to any information stored on a data storage device, including instructions, e.g., a computer program, for operating the computational device.) In particular, it can be desirable to establish a defined region of the data storage device within which data cannot be accessed without proper authorization, the defined region being treated as a separate data storage “volume.” Access to that volume (a “protected volume”) can be prevented, and authorization to access the protected volume can be determined, using conventional cryptographic techniques.
Some methods of establishing a protected volume on a data storage device are discretionary, i.e., a user must take action to cause the protected volume to be established and/or to cause data to be stored within the protected volume. For some applications, it may not be desirable to allow a user to have such discretion, since such discretion means that there is no guarantee that data generated by the user will be stored within the protected volume. (For example, a user may consciously decide not to store data within the protected volume or may inadvertently neglect to ensure that such data storage occurs.) Additionally, since a user must take action to create, and store data within, the protected volume, protection of data using these methods is not transparent to the user. However, for a variety of reasons, transparent data protection may be desirable.
Some methods of establishing a protected volume do not provide for storing data representing the operating system of the computational device within the protected volume. Failure to protect the operating system data leaves the operating system open to an attack that can corrupt the operation of the operating system, in particular in a way that may damage sensitive data. Further, failure to protect the operating system data can make data more susceptible to unauthorized access. For example, temporary files that are created invisibly by the operating system can include sensitive data. In particular, an operating system is typically, on an ongoing basis, moving data into and out of a temporary file (e.g., a swap file) that is used to provide virtual memory on a non-volatile data storage device. Thus, sensitive data can be temporarily stored on a non-volatile data storage device, as opposed to a volatile data storage device such as a random access memory (RAM), so that the sensitive data remains stored in an unprotected region of the data storage device when power to the computational device is turned off. If the operating system data is not protected within the protected volume, sensitive data stored in the swap file can be susceptible to unauthorized access. (This danger can be particularly troublesome, since it is not known which sensitive data or how much sensitive data is stored in the swap file.) Thus, it can be desirable to protect the operating system data by storing the operating system data in a protected volume and, in particular, to effect such protection before the operating system is fully operational and a user is allowed to generate data for storage on a data storage device.
It may be possible to establish a protected volume within which all of the operating system data is stored, and to establish the protected volume so that the operating system data is stored within the protected volume beginning immediately after the computational device first begins to operate after a reset (either a hardware reset or a software reset), e.g., when a master boot record is accessed or when an operating system partition is accessed. However, problems can be encountered with this approach. For example, since the operating system data is—or will be, during the boot-up sequence in which the protected volume is first established—stored within a protected volume and is therefore not available to the computational device in a “normal” manner, the functions that would otherwise be provided by the operating system when the operating system boots up (i.e., as the functionality of the operating system is progressively made available) must be duplicated by the method for establishing and/or accessing the protected volume. In particular, it is difficult and/or expensive to provide an interface to an external high assurance device (e.g., a cryptographic token) that can provide the protection mechanisms for use in creating, and controlling access to, the protected volume. (Such an interface is typically already provided by the operating system.) Provision of these operating system functions—and, in particular, provision of these functions in a way that integrates with the existing operating system—as part of the method for creating and/or accessing a protected volume can cause operation of the computational device to be unstable and unreliable.